home *** CD-ROM | disk | FTP | other *** search
/ AmigActive 25 / AACD 25.iso / AACD / Magazine / Online / QMail / docs / RFCQSBMF < prev    next >
Encoding:
Text File  |  1997-04-15  |  6.9 KB  |  156 lines
  1. The qmail-send Bounce Message Format (QSBMF)
  2. D. J. Bernstein, djb@pobox.com
  3. 19970201
  4.  
  5.  
  6. 1. Introduction
  7.  
  8.    When a message transport agent (MTA) finds itself permanently unable
  9.    to deliver a mail message, it generates a new message, generally
  10.    known as a bounce message, back to the envelope sender.
  11.  
  12.    Bounce messages produced by the qmail-send program display the list
  13.    of failed recipient addresses, an explanation for each address, and a
  14.    copy of the original message, in a format that is easy for both
  15.    humans and programs to read. For example:
  16.  
  17.       Date: 17 Mar 1996 03:54:40 -0000
  18.       From: MAILER-DAEMON@silverton.berkeley.edu
  19.       To: djb@silverton.berkeley.edu
  20.       Subject: failure notice
  21.       
  22.       Hi. This is the qmail-send program at silverton.berkeley.edu.
  23.       I'm afraid I wasn't able to deliver your message to the
  24.       following addresses. This is a permanent error; I've given up.
  25.       Sorry it didn't work out.
  26.       
  27.       <god@heaven.af.mil>:
  28.       Sorry, I couldn't find any host by that name.
  29.       
  30.       --- Below this line is a copy of the message.
  31.       
  32.       Return-Path: <djb@silverton.berkeley.edu>
  33.       Received: (qmail 317 invoked by uid 7); 17 Mar 1996 03:54:38 -0000
  34.       Date: 17 Mar 1996 03:54:38 -0000
  35.       Message-ID: <19960317035438.316.qmail@silverton.berkeley.edu>
  36.       From: djb@silverton.berkeley.edu (D. J. Bernstein)
  37.       To: god@heaven.af.mil
  38.       Subject: are you there?
  39.       
  40.       Just checking.
  41.  
  42.    This document defines qmail-send's format for bounce messages.
  43.  
  44.    In this document, a string of 8-bit bytes may be written in two
  45.    different forms: as a series of hexadecimal numbers between angle
  46.    brackets, or as a sequence of ASCII characters between double quotes.
  47.    For example, <68 65 6c 6c 6f 20 77 6f 72 6c 64 21> is a string of
  48.    length 12; it is the same as the string "hello world!".
  49.  
  50.  
  51. 2. Format
  52.  
  53.    A bounce message may be recognized as QSBMF as follows: its body
  54.    begins with the characters "Hi. This is the" exactly as shown.
  55.  
  56.    The body of the message has four pieces: an introductory paragraph,
  57.    zero or more recipient paragraphs, a break paragraph, and the
  58.    original message.
  59.  
  60.    Each paragraph is a series of non-blank lines followed by a single
  61.    blank line. The break paragraph begins with the character "-". All
  62.    other paragraphs begin with characters other than "-". The break
  63.    paragraph is human-readable but provides no interesting information.
  64.  
  65.    The introductory paragraph is human-readable. It gives the name and
  66.    human-comprehensible location of the MTA, but parsers should not
  67.    attempt to use this information.
  68.  
  69.    The only type of recipient paragraph described here is a failure
  70.    paragraph, which begins with the character "<". Paragraphs beginning
  71.    with other characters are reserved for future extensions.
  72.  
  73.    The first line of a failure paragraph ends with the characters ">:".
  74.    Everything between the leading "<" and the trailing ">:" is an
  75.    (unquoted) Internet mail address.
  76.  
  77.    A failure paragraph asserts that the MTA was permanently unable to
  78.    deliver the message to the mail address shown on the first line; the
  79.    MTA will not attempt further deliveries to that address. The
  80.    remaining lines of the paragraph give a human-readable description of
  81.    the reason for failure. Descriptions beginning with <20>, and
  82.    descriptions containing "#", are reserved for future extensions.
  83.  
  84.    The envelope sender might not have sent his message to the address
  85.    shown. There are two reasons for this. First, the MTA may freely
  86.    replace unprintable characters with "_". Second, the original 
  87.    recipient address may have been an alias for the address shown.
  88.  
  89.    The original message is an exact copy of the message received by the
  90.    MTA, including both header and body, preceded by a Return-Path field
  91.    showing the envelope sender.
  92.  
  93.  
  94. 3. Comparison with 1892/1894
  95.  
  96.    RFC 1892 and RFC 1894 together describe a format for delivery status
  97.    notifications. I have decided not to use that format, because I
  98.    believe that its complexity will prevent wide implementation and
  99.    increase the burden on people who manage mailing lists.
  100.  
  101.    QSBMF is dedicated to failure reports, whereas RFC 1894 allows
  102.    success reports and deferral reports. Although it would be possible
  103.    to add deferral paragraphs and success paragraphs to QSBMF, it would
  104.    be even easier to design separate formats for such notices. I have
  105.    trouble reading mixed failure/deferral reports.
  106.  
  107.    QSBMF always returns the entire original message. RFC 1892 allows
  108.    the MTA to return nothing or to return just the headers; it states
  109.    ``Return of content may be wasteful of network bandwidth.'' However,
  110.    failure notices are very rare, so the overall loss of bandwidth in
  111.    this case is insignificant. A much more important issue is storage
  112.    space: someone who manages a big mailing list does not want to have
  113.    to store several copies of each message in the form of bounces. The
  114.    best solution is to have each bounce automatically fed through a
  115.    program that stores only the critical information. I expect such
  116.    programs to spring up quickly for QSBMF.
  117.  
  118.    RFC 1894 provides language-independent error messages, as described
  119.    by RFC 1893. One can achieve the same results more easily by adding
  120.    structure to the human-readable failure descriptions, for example
  121.    with HCMSSC.
  122.  
  123.    RFC 1894 is able to communicate an ``envelope ID'' and the original
  124.    envelope recipient address specified by the sender. Unfortunately,
  125.    this information will almost never be available, since it requires
  126.    support by every intermediate MTA. All of the applications of this
  127.    information can be handled reliably, right now, with VERPs; this
  128.    requires support from the sender's MTA but not from other hosts.
  129.  
  130.    RFC 1894 includes several pieces of information that might be of
  131.    human interest but can be seen just as easily from Received lines:
  132.    the name of the MTA where delivery failed, the name of the previous
  133.    MTA, timestamps, etc.
  134.  
  135.    All of these RFC 1894 features have a cost: complexity. A program
  136.    cannot parse an 1894 report without parsing RFC 822 header fields
  137.    and understanding quite a bit of MIME. This will limit the
  138.    availability of parsing software. In the meantime, such reports are
  139.    annoying to mailing list maintainers, since they are full of
  140.    uninteresting information and are difficult to parse visually.
  141.  
  142.  
  143. 4. Security considerations
  144.  
  145.    Bounce messages may be forged. Never remove someone from a mailing
  146.    list without sending him a message stating that you are doing so,
  147.    even if the reason for removal is a series of apparent bounce
  148.    messages from his address.
  149.  
  150.    If you send a message along a secret path, you should change the
  151.    envelope sender address of the message to yourself, so that a bounce
  152.    will not reveal anything to the original sender. In other words: for
  153.    secret forwarding, use a mailing list, not a forwarder.
  154.  
  155.    See RFC 1894 for further discussion of these points.
  156.